Would it make sense to switch CoreCLR to use the fully managed implementation as well and get rid of the mixed-mode implementation?

The test will not actually succeed with this PR, there are two other issues. Enabling it will not be part of the final PR

Would it make sense to switch CoreCLR to use the fully managed implementation as well and get rid of the mixed-mode implementation?

It probably would, my first impression is that there isn't much use of this code from the native side (except perhaps those TypeString functions)

Thank you for the feedback! This is a WIP:

• I have not yet formatted the code, a lot is sourced from CoreCLR but I was following the Mono style. @marek-safar which style do you want for new files? It looks like there's desire to share this code in both runtimes so I think CoreCLR-style.

• Some of the code structure is dubious but not clearly from the beginning, e.g. Clear() seemed to be set up for reusing the internal C++ class, but there was no actual use of it that way AFAICT. I have some more cleaning to make.

• This looks like it can be refactored to be thread-safe by not using the TypeNameBuilderImpl that is stored in a field, so I will probably do that.

there's desire to share this code in both runtimes

In that case, it should follow the existing code style of shared SPC sources. I don't know what is the intention for CoreCLR but maybe it could land in the shared location instead of mono from the start

Update:

• Applied feedback, moved/renamed file to shared S.P.C location
• This is now thread-safe; TypeNameBuilderImpl now contains all the state and a new one is used for each call to ToString. The class interface to TypeNameBuilder has not changed.
• Experimenting with using it in CoreCLR (not done properly, have not removed files, just want to see CI's response)

Looks like System.Collections.Stack isn't in CoreCLR's CoreLib (while System.Collections.Generic.Stack is missing from Mono's)

TypeNameBuilderImpl now contains all the state and a new one is used for each call to ToString. The class interface to TypeNameBuilder has not changed.

I do not see a reason for this split. Can all state and methods from TypeNameBuilderImpl be moved to be private state and methods on TypeNameBuilder ?

@jkotas I think all issues are resolved except how to keep the parser state checks. I like them because they were part of the original and this is still a port of that code, which has now changed considerably and could do with some checking. I also don't think they will have a real impact in a program's performance. But I understand they add some IL and an extra class to CorLib, so increase its size.

Is the only way you would have them is in #if DEBUG blocks? That is probably too ugly because there's a bunch of single statements, and I will probably just take them out then. Would it be agreeable to leave them as comments?

I can also ask the compiler for aggressive inlining for CheckParseState, to prevent the no-op calls on release.

@marek-safar Are you ok with keeping debug-only ParserState cruft in release builds, or do you prefer to have it conditionally excluded?

As I have said above, the value of these debug-only checks seems to be very low, and I believe it would be best to delete them.

LGTM otherwise. Thanks!